The present invention relates to computer systems for the management of information distributed across a plurality of electronic system devices. More particularly, the invention relates to a system which includes a plurality of network servers, interface terminals, remote data collecting devices and other smart devices to facilitate information collection, approval, editing and storage such that the network server storage location of specific information can be specified using a remote collecting device. The invention also relates to record verification methods.
As an initial matter, in the interest of simplifying this explanation and unless indicated otherwise, the description which follows describes the invention in the context of a medical facility. However, it should be recognized that the invention should not be so limited and clearly has applications which are outside a medical facility, only some of which are specifically discussed hereinafter.
In many industries a need exists for remote information collection and information storage which facilitates easy subsequent information retrieval. For example, in medical facilities there is a need, for purposes of patient protection, quality control, record keeping, billing, and forensics, to monitor, control, and record access to medicine dispensation, medicine administration, IVs, blood transfusions, and other treatments as well as the collection, administration, and testing of blood and tissue samples. These events have traditionally been controlled and monitored manually by doctors, nurses and other facility personnel (hereinafter “physicians” generally).
Unfortunately the increasing specialization and complexity of medical care has vastly increased both the types and amount of routine record keeping that is required to track all events which occur in a facility. Advantageously, rapid growth of computer technologies has provided tools which can be used to store and retrieve specific information from a vast quantity of medical records. In particular, Internet technology is now routinely used to create hospital Intranets, link discrete hospital databases and make their data, images, and audio video records commonly accessible.
Most medical facility Intranet systems include a plurality of network servers disposed in either one central information systems department or at various locations throughout the facility, a plurality of computer terminals located throughout the facility and a data bus which links all of the servers and computers together. Software is loaded onto each computer to facilitate information entry and specify server addresses for information retrieval and storage.
The first Intranet systems were used for only very few applications and therefore were not extremely complex. However, over time, as Intranet applications became more numerous and their use as information management tools became more widely recognized, single server systems could no longer meet the information management needs of even a single medical facility. This information management capacity problem has been exacerbated by prolific mergers and acquisitions among medical groups such that many medical groups now have several locations and vast amounts of information to manage.
To facilitate information management on such a huge scale Intranet systems have evolved over time. In most cases, so as to increase management capability without wasting existing capability (i.e. without completely replacing existing servers and computers), instead of replacing entire Intranet systems, additional servers and computers are simply added to an existing Intranet network.
While this piecemeal approach to Intranet enhancement minimizes hardware costs, this approach results in an extremely complex system wherein it is often relatively difficult to direct information to known electronic memory locations (i.e. server storage addresses) which are later easily accessible. While such storage addresses could be manually provided, providing such addresses manually is particularly cumbersome as many addresses are complex and difficult to specify. This is because a single facility or related facilities may employ many different servers and each server may have access to several different memory devices. Addressing schemes have been further exacerbated by the Internet where there may be several thousand servers and it would be impractical for a user to attempt to manually enter every server address used for storage.
To overcome the addressing problem most Intranet servers are equipped to automatically assign server addresses to specific types of user provided information. To this end, a browser is typically loaded onto each Intranet capable computer which communicates with system servers. When a user contacts a server to interact therewith (i.e. to provide information thereto or receive information therefrom), the server sends instructions to the browser indicating what should be displayed on the computer screen. Typically the screen indicates the server which originated the browser instructions, includes hyperlinks to various related server addresses, includes some instructions on how to use the server via the browser and provides blanks for entering information which is to be returned to the server for storage or processing.
In addition the server provides addresses to displayed hyperlinks and for information which is to be entered by a user. Typically the server provided addresses are held in computer memory and not displayed. After the physician indicates that information has been entered or selects a hyperlink, the browser software transmits the information to the server or contacts the server indicated by the hyperlink address.
Where information is sent to a server, when the server receives information the server may do any of a number of different things including storing the information at a server address or some type of processing and sending additional instructions to the browser. Where a user selects a hyperlink the server indicated by the hyperlink address responds to the selection by providing a different set of browser instructions for configuring the browser screen.
For example, in the hospital environment a first browser screen might display several user selectable hyperlinks for entering different types of information into the system and no blanks for entering information. For instance, a first hyperlink may be to a pharmacy server to request a screen presentation to enter pharmacy information, a second link may be to a billing server, a third link may be to a patient history server and a fourth link might be to a prescription server. In this case, to enter information the user first has to select one of the hyperlinks.
When a hyperlink is selected, the server indicated by the hyperlink address provides instructions to the browser for configuring the browser screen. For example, a server used by a pharmacy may provide instructions to configure a screen including, along with instructions for filling in blanks, a first blank for entry of a patient's name, a second blank for entry of a physician's name, a third blank for entry of a dispensed drug and a quantity indicator and a fourth blank for entry of the dispensing date and time.
After a physician indicates that required information has been provided, the browser transmits the information to the pharmacy server. When the server receives the information the server stores or processes the information and then typically returns a message indicating that the information has been stored or processed.
After a pharmacy-record has been stored, when a pharmacist reviews records on the pharmacy server the pharmacist can verify, among other things, that a specific prescription was dispensed, the date and time of dispensing, which patient received the prescription and which physician dispensed the prescription.
To enter some other type of information such as billing information, using the first screen, a physician might select a second billing server hyperlink. When the second hyperlink is selected, the billing server provides screen configuration instructions and a return target address for information to be returned to the server for storage. The browser displays the billing input screen and waits for the physician to indicate that information has been provided. Thereafter the provided information is transmitted to the server at the target address and is either stored or processed. In this manner all information addressing and control is facilitated by the servers, not the system user.
While such information receiving and addressing systems can meet the information gathering needs of some facilities, such systems have a number of shortcomings. First, information gathering and entry into such a system is extremely time consuming and therefore is often thought of as an onerous task which is to be avoided. For example, in a medical facility, when a physician makes her rounds, the physician may visit with twenty or more patients, performing examinations and procedures, diagnosing illnesses and prescribing and administering drugs. Each visit requires information gathering related to symptoms, diagnosis, prescription, procedures and examinations performed and drugs prescribed and administered. When this information is gathered via a pen and clip board, the information must later be entered into the system and stored at a specific and accessible location,
Most physicians are not particularly adept at data entry. In addition, most physicians are extremely busy and therefore do not have the time to personally enter written information into a system via a browser. For these reasons either information is never entered into a system or a person specifically earmarked for data entry is required. While a data entry person may be expensive, the alternative (i.e. not entering the information into a searchable form) is not acceptable as information must be properly archived.
Second, even where a data entry person is provided, under the press of time many physician's have developed their own, personalized shorthand to expedite note taking during patient visits. In addition, often physician's writing styles are very different making it difficult at best to decipher hand written records during data entry. Shorthand and sloppy or varying writing styles make data entry by someone other than a physician extremely difficult.
Third, when information is entered into a system manually by someone other than a physician, the likelihood of mistakes is extremely high due to imperfect translation of handwritten notes, the fact that entry personnel typically are not trained in medical terminology and the fact that many medical terms are very similar, thereby increasing the likelihood that one term may be substituted for another.
Fourth, because tolerance for errors in medical records is extremely low, there should be some way to force physicians to check the accuracy of system records prior to allowing permanent storage. The present server/browser systems do not require physician approval of records prior to storage. In other words, in many cases a data entry person may enter a physician's notes and the physician may never check the notes for accuracy.
Fifth, even when someone other than a physician enters information into a system and a physician intends to revisit the information prior to permanent storage to check accuracy, despite the importance of record review, because of the press of time, record review by physicians is typically low on a physician's priority list. Where a physician allows even a few days to pass prior to reviewing information for approval, a physician's recollection of what transpired during a patient visit may not be accurate and information errors may result.
Sixth, even where a physician takes on the task of entering all information into a system to ensure quality control, the task of moving about from one browser screen to another to input information which is directed to correct server storage locations is onerous where many different records have to be entered and stored. For example, a physician may collect twenty different records while making rounds. Five of the records may have to be stored in patient record's on a patient history server, five records may have to be stored on a pharmacy server, five records may have to be stored on a billing server and the remaining five records may have to be stored on an inventory server. In this case, the physician would have to jump from one browser screen to another during data entry to enter the twenty records into the system. While this simple task might not be objectionable where there are only a few records, clearly, as the number of records which a physician is expected to make increase, the task of jumping among different browser screens becomes more taxing.
Seventh, in many cases some information may have to be provided to many different servers and therefore might have to be entered by a physician or a data entry person more than once. For example, where a drug is prescribed for a patient drug dispensation and administration information may have to be provided to many different servers for different purposes. A pharmacy server may require an administration record to ensure that a drug has been delivered, a billing server may require a record of dispensation for billing purposes, a patient record server may have to be updated to indicate that the drug was received, when the drug was received, the quantity of the drug received, the physician who administered the drug and so on, an inventory server may require an administration record to update an inventory list and automatically order drugs to meet anticipated requirements, etc. To provide all of these records to all of the servers, a physician would have to access four different browser screens, a separate browser screen for each server, and duplicative information would have to be entered to be delivered to each server.
Eighth, typical systems do not make any record of who approved information entered into a system and therefore there is no way to determine if an authorized physician approved a record or some clerical personnel accidentally approved a record before storage.
Various electronic devices have been developed to aid in the information gathering task. One handy information gathering device is the dictation device (DD) which can be used to record a physician's audio (i.e. voice) notes during a patient visit. To this end, a typical DD includes a processor, a memory (typically an electronic memory), a microphone, a speaker and some type of activation button. To take audio notes a physician positions the activation button in a record position and speaks into the microphone, the processor recording all voice notes in the memory. DDs often also allow audio review of oral notes and re-recording features to correct mistakes.
In facilities where physicians regularly use DDs, recorded notes are provided to data entry personnel who manually type audio records into an Intranet computer terminal for storage on a server. In the alternative, recently some software has been developed which can automatically convert audio records into text files for digital storage.
While DDs are preferred by some physicians, DDs do not overcome many of the shortcomings of manual (i.e. pen and paper) record keeping which are discussed above. For example, unless a system includes voice recognition software, data entry personnel are still required, physician shorthand causes transcription problems for both a data entry person and transcription software, mistakes may be made during transcription due to imperfect dictation and complex medical terminology, there is no procedure to ensure that information accuracy is checked or to indicate who approved information prior to permanent storage and it takes a large amount of time to enter information into the system.
Another handy information gathering device is a hand held device (HHD) which streamlines the information gathering process and the process of entering information into an Intranet system. To this end, a typical HHD may include a keyboard or the like, a processor, a memory and a transmitter. The board takes the place of a conventional clip board and is used to manually and remotely enter information which the processor stores in the memory. After information has been entered via an HHD, to provide the information to the system, the HHD transmitter is positioned in close proximity to a computer input device and the information is transmitted to the input device via a message including a series of signals.
To intelligibly receive a transmitted message and provide information contained therein to a browser for ultimate delivery to a server for storage or processing, a message receiving computer must be capable of translating the transmitted message into the language used by the server which is typically the hypertext markup language (HTML). This task is accomplished in one of two ways. First, the input device may include special dedicated hardware which converts the message into HTML, the hardware resembling a disk drive in the way it interacts with a browser. Second, the input device may simply provide the received message to the computer processor and software loaded onto the processor might be designed to translate the message into HTML.
Thus, HHDs can be used to eliminate physician's hand written notes thereby streamlining the data gathering/entry process. In addition, as a physician enters information into an HHD, the physician can approve entered information immediately eliminating the need to later revisit the information for approval.
While HHD technology goes a long way to solving many of the problems associated with remote information gathering, problems still exist. First, it is likely that physicians will object to having to manually enter information into an HHD for the same reasons that physicians object to entering information into regular computer terminals. In addition, with an HHD information entry is even more objectionable because most HHD keyboards are relatively small.
Second, patient's will likely object when they perceive that a physician's time during a visit is split between the patient and an HHD for information entry. This is particularly true in the case where it might be difficult to enter information into the HHD thereby requiring additional data entry time.
Third, even if there were some quick way to enter information into an HHD, transmission of the information from the HHD to a browser and ultimately to a server for storage or processing is a relatively complex task. For example, assuming five records are stored in an HHD for transmission to a browser and that each of the five records is different such that each record ultimately has to be stored on a different server. In this case, prior to transmitting each record to the browser, the physician would have to select the proper browser screen for data transmission. For example, if the first record is to be stored on a pharmacy server, the physician has to select the pharmacy browser screen prior to transmitting the first record. After the first record is transmitted to the browser the browser then provides the record to the pharmacy server which is associated with the screen. Next, assuming the second record is to be stored on the a billing server, the physician has to select the billing browser screen prior to transmitting the second record. After the second record is transmitted the browser provides the record to the billing server. Not only is this process cumbersome, but the HHD would have to have some mechanism which indicated to the physician which record is queued up for transmission so that the physician could select the proper browser screen and associated server address.
Fourth, conventional HHDs do not indicate who approved a record for ultimate storage.
Fifth, again, where duplicative information must be provided to several different servers, a physician has to separately select a browser screen associated with each server and transmit the information to be stored once for each server which is to receive the information. This is time consuming and therefore objectionable.
Some HHDs have been designed to facilitate a pseudo-addressing scheme whereby an ultimate server target address can be selected for some specific types of HHD information. For example, some HHDs allow a user to enter an E-mail address for a message to be delivered via an Intranet or Internet system.
At first blush an HHD which specifies a pseudo-address appears to overcome many of the problems associated with transferring information from an HHD to a server for ultimate storage. Thus, if server addresses can be specified, a single generic browser screen can be used as an intermediary between an HHD and servers, the HHD, not the servers, specifying where HHD information should ultimately be delivered for storage or processing.
Unfortunately, instead of simplifying the information management task, pseudo-address specifying HHDs add a new wrinkle of complexity to a browser system. To this end, while existing address specifying HHDs can provide both information (i.e. a message in the case of E-mail) and an ultimate target address, a dedicated “clearing house” server is required for a number of purposes. First, because the HHD cannot specify configuration of a browser screen, a clearing house server is required for screen configuration.
Second, because Intranet addresses are often extremely complex and difficult to manually specify, to simplify address specification, HHD provided addresses usually take a short hand form which in and of itself cannot be used by a browser to direct information to a specific server. The short hand address is provided to the clearing house server via the browser. Thereafter, the clearing house server uses the short hand address to formulate a more detailed target address specifying a different server for message delivery. Thus, the clearing house server must have some clearing house software for processing received information.
Third, in addition to providing browser screen configuration information, the clearing house server also has to specify the clearing house server address so that HHD information and the short hand target address are provided to the clearing house server for further distribution.
In short, even where an HHD can provide a pseudo-address for targeting information, a dedicated clearing house server with special processing software is required.
To appreciate the added wrinkle of complexity in systems which facilitate pseudo-address specification, consider an exemplary system including HHDs which can specify E-mail messages and associated pseudo-addresses. In this case, to provide an E-mail message to an Intranet, an HHD user must first select an E-mail browser screen via a computer. When the E-mail screen is selected, the computer communicates with an associated E-mail server which provides information to the browser including screen configuration information and the E-mail server address. The browser thereafter displays a properly configured screen for receiving information from the HHD.
Next, the HHD user positions the HHD in close proximity to a computer input device and transmits the E-mail message, including E-mail address, to the browser. The device provides the message and E-mail address to the browser which in turn transmits the message and E-mail address to the E-mail server specified by the server address associated with the screen. When the E-mail server receives the message and E-mail address, the E-mail server uses the E-mail address to form a relatively more complex address specifying the target for the E-mail message and then transmits the E-mail message to the more complex address and intended recipient. Clearly this system is more complex than a typical Intranet system as a dedicated clearing house server is required for both screen configuration and additional processing.
One advantage of conventional paper type reporting systems is that original documents can be authenticated simply via a personal signature. Thus, to determine authenticity an original document can be located and a signature examined.
Unfortunately, often original documents cannot be located for authentication. Because copies are easy to manipulate (e.g. signature cut and paste and general information modification), document copies usually cannot be relied upon for verification of their content. Usually, the only reason copies are relied upon is because original documents cannot be retrieved.
Document authentication problems are further exacerbated in the digital realm as document modification and signature picture cutting and pasting is relatively easy using standard computer functions. Thus, for example, where a document is transmitted from one computer to another and includes some type of signature picture, it would be advantageous to have some way to authenticate the content of the received document.
One solution to this authentication problem is described in U.S. Pat. No. 5,689,567 (the “'567 patent”) which is entitled “Electronic Signature Method and Apparatus,” which issued on Nov. 18, 1997. In the '567 patent, to enable document authentication of a digitally stored document which is subsequently accessed, prior to storing the document, a digital signature picture is encrypted as a function of the document content and is further encrypted as a function of a private (i.e. secret) key. The encrypted signature picture and document are stored.
Thereafter, when the document is reaccessed, the signature picture is decrypted using a public key and as a function of the document content thereby generating the document including a signature picture. Where the document is authentic, the resulting signature picture matches the original signature picture. Authentication is performed by visually comparing the resulting signature picture to the original signature picture.
While the '567 patent invention is useful, the '567 invention has a number of shortcomings. First, after a document is retrieved and decrypted, often it will be useful to store the document in a more accessible form such as in the form of a conventional word processor document, spread sheet, etc. In this case, after the initial decryption, there is essentially no way to subsequently authenticate a document. Thus, for instance, after a word processor document is generated and stored in decrypted or plain text form, the document may not again be accessed for a long time (e.g. years). The next time the document is accessed, because of the passage of time, it may be desirable to re-authenticate. The '567 reference does not facilitate re-authentication.
Second, it is often advantageous to generate a hard copy (i.e. paper) of a digital document for more conventional storage or conveyance to another party. Again, the '567 patent facilitates a first authentication by visual comparison but thereafter authentication is impossible. For example, after a paper document with a digital signature picture is generated, the paper document may be stored in a conventional binder-type file for a long time (e.g. 5 years). Thereafter, the paper document may be retrieved for review. When retrieved there is no way to authenticate the document. This problem is exacerbated by the fact that many documents are copied and copies of documents are copied and, as with an original paper document which is digitally signed there is no way to authenticate a copy.
Thus, it would be advantageous to have an information gathering system for remotely gathering information, reviewing and approving information, identifying who generated information and identifying who approved information prior to storing the information. In addition, it would be advantageous if such a system facilitated easy downloading of the information from an information gathering device to a browser for ultimate transmission to a server for storage or processing. Moreover, it would be advantageous if such a system could be used with a conventional Intranet and did not require a dedicated clearing house server or specialized server software. Furthermore, it would be advantageous to have a system which can authenticate either a hard copy or a digitally stored document by simply analyzing information provided on the document.
Many devices and software programs have been developed to improve the security of computers and computer networks. Securing computers and networks is essential to protect confidential information, to prevent fraud, and to ensure that computers are not compromised by amateur hackers for their entertainment or by terrorists intent on disrupting or endangering public safety.
The public has seen the effects of insecure computer systems in recent years including the mass release of customer credit card numbers, the use of computers by hackers to launch denial of service attacks, and outright theft from e-commerce sites. These and other events threaten to undermine the public's interest in using computers for conducting a variety of online business activities referred to as e-commerce.
Today and for the last thirty years the most prevalent form of security is the use of software to request from a person who wants to use a computer his user name and password. This information is typically sent to a remote security server, which uses the unique user name to look up the corresponding password for that person. Then the entered password is compared with the stored password, when there is a match the person is grated access to the computer, if not they are denied access.
Unfortunately, user name and password schemes can often be overcome by hackers attempting to guess common passwords, e.g. “xxx”, “123”, blanks spaces, and the default password for many systems “password”. In an attempt to fortify passwords, computer users are sometimes required to use long password strings (e.g. at least 8 characters), to use passwords that combine letters with numbers and/or punctuation marks, to change their password every month or so, and to prevent the reuse of a prior password for a year or longer. However, the security improvements are often illusionary; as password get longer, more complicated, or change frequently users tend to write them down, as they can't remember them. The users then leave the written password in a place that is all to often easily found, e.g. taped to the underside of keyboard, in their desk drawer, or other common location.
Another problem with complicated or changing passwords is that users who do not write them down frequently forget them. This results in their not being able to use their computers, which forces them to call the computer system help desk for assistance in recalling their password or resetting their password to allow the user to enter another new complicated password, which they probably will also forget or write down. The user now can continue to work, but the computer help desk staff is thus conditioned to expect a large number of users to forget their passwords. This allows a hacker or other person to attempt to impersonate one of the computer users to gain password information, after all the help desk cannot really verify the identity of the person calling by telephone.
Passwords are also disliked by those users who need to use computers for very short periods throughout the day, forcing them to enter the user name and password (e.g. this may require 15 seconds) in order to view one value or measurement (e.g. this may only take 3 seconds) and then log off. Nurses, physicians, and many factory workers have this problem; effectively spending more time logging on and off of a computer than the time they spend using it. Furthermore for very busy environments, the constant authentication and reauthentication of users can create a drain on network bandwidth and strain the security server.
Once the user has properly entered a password he is typically admonished to logout when leaving the workstation environment to prevent unauthorized access. The system may automatically log a user off after a predetermined period of inactivity. For users who must access the system frequently but intermittently, short inactivity periods for automatic logout will be a source of constant inconvenience. Alternatively, if long inactivity periods are used, another user may inadvertently use the terminal under the previous person's security authorization.
To improve the security of computer systems a number of other technologies have been developed, but are they used in relatively low numbers. One of the most common technologies includes the use of a biometric indicia (fingerprint, iris image, voice, facial image, etc.) that is measured or sensed and sent to a remote security server. The server compares the indicia against a database of indicia for registered users. To speed the process up and to make it more specific, the user is usually requested to enter a user name. Now the server only has to compare the measured or imaged indicia against the stored indicia corresponding to the entered username. In some cases the user may be further asked to enter a password creating what is sometimes referred to as a two factor authentication system.
However, these systems can take a long time to determine if there is a match or not and none of them are perfect. Each tolerates a level of false positives in order to ensure the level of false negatives, which irritate the user by rejecting them, are kept to a minimum. Furthermore these systems can be confused by biometric indicia changes (laryngitis for voice imagers, finger cuts or trauma for fingerprint readers, or shaving facial hair for face detectors). In some environments it is not easy to measure the biometric indicia, for example fingerprints for workers wearing protective gloves (e.g. nurses, those exposed to environmental extremes) or facial features for workers wearing hats or masks (e.g. when the temperature is extremely cold).
In situations where computers users frequently use a computer for a period of time, leave it for a while, and then later user it or another again, biometric indicia measurements can be a substantial drain on the users' time. They spend more time being authenticated than using the computer.
Other technologies used include smart cards with or without proximity detectors and electronic token generators. A smart card can be inserted into a reader attached to a computer, which reads a special code (e.g. time varying codes) and sends that to the security server often with a user name and password, also creating a two factor user authentication. When the user is finished working at the computer they must be careful to remove the smart card otherwise anyone else can use the computer. When a smart card can be detected by wireless proximity means, the user gains access as mentioned but by leaving the computer they can be logged off the computer when the card can no longer be detected. This prevents anyone else form using the computer without authenticating himself. In some cases smart cards are used with biometric indicia to create a three factor user authentication. While smart cards can provide a higher level of security they are at least as time consuming as passwords for workers who use computers for short periods of time, frequently throughout the day.
Electronic token generators are typically calculators that compute time varying codes that are presented to a user via a LCD screen. The user who wants to access a computer uses a terminal to enter their user name, the current code, and sometimes a password as well. This is received by a security server, which compares the code with an algorithm that is unique for the specific user to determine if the user and the entered code match. Token generators are particularly disliked when the user must access computer terminals frequently throughout the day as they must examine the token and enter the long numeric value properly.
Another restricted access system involves the use of user-specific password-generating devices. Typically, a user seeking access to a secure system is presented a code or instruction on a system terminal screen. The user enters the code or the information demanded by the instruction, via manual entry or optical coupling, into his own password generating device. The password generating device then calculates a second code based upon the user's input and an encryption algorithm stored by the device, and displays this second code to the user for entry into the computer terminal or workstation. After the user enters the second code, the computer terminal or workstation then performs a verification check on it to confirm its creation by the password calculator of an authorized user of the computer terminal or workstation. If confirmed, the user is granted access in accordance with the user's system access privileges.
Yet another restricted access system requires a user to insert an authorization card, e.g. a PCMCIA card, into a computer card reader to authorize access and to authenticate information entered at the computer terminal with the users digital signature. One potential weakness of such a system is that a hidden program could present documents for signature without the proper control of the user. Another weakness with these implementations is the relatively high risk that an authorized user will forget to or fail to remove his card in the card reader before he leaves the terminal—a risk that is particularly acute for a nurse or doctor who may have to leave a terminal in emergency situations to attend to a patient's care. Also, the loss of the card will result in a significant inconvenience to the owner and the system administrator.
Lemelson, in U.S. Pat. Nos. 5,202,929 and 5,548,660, discloses an access control system utilizing detection devices such as speech recognition equipment and fingerprint scanners to analyze one or more physical characteristics of a person attempting access to a computer. The system also incorporates physical presence sensors such as motion detectors and limit switches embedded in seat cushions to track the presence of an authorized user so as to prevent continued access to the system when the authorized user leaves or is absent. This system is primarily directed to accessing desktop computer terminals on a sensitive computer network and is not easily adaptable, however, for restricting access to laptops, portable instruments, medical equipment such as respirators, or electronically-controlled medication dispensers. Moreover, the implementation of the Lemelson invention requires a significant amount of detection equipment and analysis software, which may not be adaptable to the cost, space, and portability requirements of many devices for which restricted access and auditing control is desired.
Users and system owners need improved user authentication systems that do not impede the workflow, yet maintain a higher level of security and to do not slow down security servers with constant reauthentications.